Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mpv-plugin/open-in-mpv-bin: new package, add 2.3.0 #252

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

vitaly-zdanevich
Copy link
Contributor

@vitaly-zdanevich
Copy link
Contributor Author

@pastalian please review

@pastalian
Copy link
Contributor

I don't really have any comments on this ebuild. You should get approval from guru-trusted, which I'm not a part of.

@stkw0
Copy link
Contributor

stkw0 commented Oct 31, 2024

Could we have a non -bin ebuild? It seems doable

@vitaly-zdanevich
Copy link
Contributor Author

Ok, but it is also good to have -bin as a backup, and for simplicity - so user can install it without Go compiler. I will create source-based ebuild after merging of this one - do not want to mess with git branches.

@stkw0
Copy link
Contributor

stkw0 commented Nov 1, 2024

About "backups", that's why we usually left at least one older version, so if a new version is broken one can switch to the older one.
As for simplicity, -bin packages complicates things. It's harder to have consistency across the system, it's harder to unbundle libraries, it's more complicated to get security updates if it builds with static libraries.

Only when a package is arguably difficult to build from source (eg: electron programs) or there is some other justification (eg: very big build times as with libreoffice) it's reasonable to have a -bin version. I don't find any good reasons to have a binary ebuild for this, so I am not merging it.

@vitaly-zdanevich
Copy link
Contributor Author

But why Gentoo added binary mirror for all packages? https://www.gentoo.org/news/2023/12/29/Gentoo-binary.html

To speed up working with slow hardware and for overall convenience

@stkw0
Copy link
Contributor

stkw0 commented Nov 2, 2024

As you quote it, for slow hardware and programs that take a lot to compile. Because adding a duplicated -bin ebuilds is a very poor solution, and because portage had supported binhosts for a lot of years. Traditionally, if you wanted binaries, you created your own custom binhost. Now Gentoo is kind enough to provide and maintain an official binhost for people who might want it.

Another important point is that portage will detect if the USE flags are different or there is some change between the binhost and your computer in which case it will fall back to compile the program instead of graving the binary. This keeps the coherency of your system, which is much harder to do when one installs pre-compiled binaries without any kind of checking of how those binaries were built.

If you want binaries for arbitrary packages, create your own binhost with whatever is convenient for you. See https://wiki.gentoo.org/wiki/Binary_package_guide

@vitaly-zdanevich
Copy link
Contributor Author

ok, asked upstream about vendoring Baldomo/open-in-mpv#37

@stkw0
Copy link
Contributor

stkw0 commented Nov 5, 2024

As it says in the wiki, you can also upload the tarball to Github and create a tag for each release.

@MrRoy
Copy link
Contributor

MrRoy commented Nov 18, 2024

@vitaly-zdanevich the procedure to package the dependencies is documented here: https://wiki.gentoo.org/wiki/Writing_go_Ebuilds#Packaging_the_dependencies
You can host them on a GitHub or GitLab repository at not cost to you.

It is the packager's job to package dependencies for Gentoo, not upstream. If you will not do it, then please close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants